Method and system for sharing content in videoconferencing

ABSTRACT

Content presented in association with a transmitting endpoint is obtained by the transmitting endpoint and transmitted to a receiving endpoint of a videoconference, along with associated information regarding interaction of a presenter with the content at the transmitting side. The receiving endpoint presents the presented content obtained from the transmitting endpoint similar to the presentation format at the transmitting side. Where the original presentation format is not suitable for transmission, a video image of the content in the original presentation format may be transmitted. An intermediate control unit, such as a multipoint control unit, may relay content and associated information between transmitting and receiving endpoints.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.14/283,691 filed May 21, 2014, which claims the benefit of U.S.Provisional Application filed May 24, 2013, entitled “METHOD AND SYSTEMFOR SHARING CONTENT IN VIDEOCONFERENCING,” the contents of both of whichare incorporated herein in their entirety.

TECHNICAL FIELD

The present invention relates to video communication and moreparticularly to the field of presenting content in videoconferencing.

BACKGROUND ART

As traffic over Internet Protocol (IP) networks and other type ofnetworks continues its rapid growth, and with the growth of the varietyof multimedia conferencing equipment, more and more people usemultimedia conferencing as their communication tool. A plurality ofvideoconferencing types of session require content to be presented withthe video image. Business meetings, educational sessions, lectures,marketing presentations, professional meetings (such as design reviews),etc. require content presentation. Different types of content such asEXCEL® tables, POWERPOINT® presentations, slides, charts, drawings, etc.may be presented during a video conferencing session. EXCEL andPOWERPOINT are registered trademarks of Microsoft Corporation.

Usually the content is important for understanding the currentdiscussion; therefore, the content is delivered to all the conferees.Today, at a delivery endpoint, content is converted to video stream bycapturing, few times per second, the image of the screen of the computerthat runs the presentation. Then the video stream of the presentationmay be compressed by an encoder in addition to the encoder that is usedfor handling the video stream of the conference. In most cases, theframe rate used by the encoder to compress the content is low, 1 to 10frames per second for example. The compressed content may be sent fromthe delivery endpoint toward a multipoint control unit (MCU) over aseparate stream using a different channel than the endpoint video image.From the MCU the content may be sent toward one or more receivingendpoints as video switching over a separate stream other than thecontinuous presence video image of the conference. The parameters of thecontent encoder are negotiated to the highest common parameters. In somevideo conferences, the MCU may transcode the content that is sent towardone or more receiving endpoints. Further, for some limited endpointsthat cannot handle the content as a separate video stream, the MCU maytreat the content as a video stream from an endpoint, and may add it toa segment in the continuous presence video image that is targeted towardthe limited receiving endpoints.

An MCU is a conference controlling entity that is typically located in anode of a network or in a terminal that receives several channels fromendpoints. According to certain criteria, the MCU processes audio andvisual signals and distributes them to a set of connected channels.Examples of MCUs include the MGC-100™, RMX 2000®, which are availablefrom Polycom, Inc. (MGC-100 is a trademark of Polycom, Inc. RMX-2000 isa registered trademark of Polycom, Inc.) A terminal, which may bereferred to as an endpoint, is an entity on the network, capable ofproviding real-time, two-way audio and/or video and/or content visualcommunication with another endpoint or with an MCU. A more thoroughdefinition of an endpoint and an MCU may be found in the InternationalTelecommunication Union (“ITU”) standards, such as but not limited tothe H.120, H.324, and H.323 standards, which may be found at the ITUwebsite: www.itu.int.

SUMMARY OF INVENTION

Content presented at a transmitting endpoint is obtained by thetransmitting endpoint and transmitted to a receiving endpoint of avideoconference, along with associated information regarding interactionof a presenter with the content at the transmitting endpoint. Thereceiving endpoint presents the presented content obtained from thetransmitting endpoint similar to the presentation format at thetransmitting endpoint. Where the original presentation format is notsuitable for transmission, a video image of the content in the originalpresentation format may be transmitted. An intermediate control unit,such as a multipoint control unit, may relay content and associatedinformation between transmitting and receiving endpoints.

These and other aspects of the description will be apparent in view ofthe attached figures and detailed description. The foregoing summary isnot intended to summarize each potential embodiment or every aspect ofthe present description, and other features and advantages of thepresent description will become apparent upon reading the followingdetailed description of the embodiments with the accompanying drawingsand appended claims.

Furthermore, although specific embodiments are described in detail toillustrate the inventive concepts to a person skilled in the art, suchembodiments are susceptible to various modifications and alternativeforms. Accordingly, the figures and written description are not intendedto limit the scope of the inventive concepts in any manner.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate an implementation of apparatusand methods consistent with the present invention and, together with thedetailed description, serve to explain advantages and principlesconsistent with the invention. In the drawings,

FIG. 1 schematically illustrates a simplified block diagram withrelevant elements of a videoconferencing system according to oneembodiment.

FIG. 2 schematically illustrates a simplified block diagram withrelevant elements of an embodiment of a conferee's computer and acontent transmitting endpoint according to one embodiment.

FIG. 3 schematically illustrates a simplified block diagram withrelevant elements of an embodiment of an intermediate node according toone embodiment.

FIG. FIG. 4 schematically illustrates a simplified block diagram withrelevant elements of an embodiment of a content receiving endpointaccording to one embodiment.

FIG. 5 is a flowchart illustrating relevant actions of a method that maybe used for content transmitting that may be implemented by a contenttransmitting endpoint according to one embodiment.

FIG. 6 is a flowchart illustrating relevant actions of a method that maybe used for content receiving and transmitting that may be implementedby an MCU according to one embodiment.

FIG. 7 is a flowchart illustrating relevant actions of a method that maybe used for content receiving and presenting that may be implemented bya content receiving manager module according to one embodiment.

DESCRIPTION OF EMBODIMENTS

Turning now to the figures, in which like numerals represent likeelements throughout the several views, embodiments of the presentdescription are described. For convenience, only some elements of thesame group may be labeled with numerals. The purpose of the drawings isto describe embodiments and not for production. Therefore, featuresshown in the figures are chosen for convenience and clarity ofpresentation only. Moreover, the language used in this description hasbeen principally selected for readability and instructional purposes,and may not have been selected to delineate or circumscribe theinventive subject matter, resort to the claims being necessary todetermine such inventive subject matter.

Reference in the specification to “one embodiment” or to “an embodiment”means that a particular feature, structure, or characteristic describedin connection with the embodiments is included in at least oneembodiment of the invention, and multiple references to “one embodiment”or “an embodiment” should not be understood as necessarily all referringto the same embodiment.

Although some of the following description is written in terms thatrelate to software or firmware, embodiments may implement the featuresand functionality described herein in software, firmware, or hardware asdesired, including any combination of software, firmware, and hardware.In the following description, the words “unit,” “element,” “module” and“logical module” may be used interchangeably. Anything designated as aunit or module may be a stand-alone unit or a specialized or integratedmodule. A unit or a module may be modular or have modular aspectsallowing it to be easily removed and replaced with another similar unitor module. Each unit or module may be any one of, or any combination of,software, hardware, and/or firmware, ultimately resulting in one or moreprocessors programmed to execute the functionality ascribed to the unitor module. Additionally, multiple modules of the same or different typesmay be implemented by a single processor. Software of a logical modulemay be embodied as instructions stored on a computer readable mediumsuch as a read/write hard disc, CDROM, Flash memory, ROM, or othermemory or storage, etc. In order to execute a certain task, a softwareprogram may be loaded to an appropriate processor as needed. In thepresent description the terms task, method, process may be usedinterchangeably.

Converting content from its origin format into compressed video andassociating it with the video of the conference reduces the quality ofthe presented content. Video compression uses lossy compressionalgorithms, therefore each encoding/decoding cycle along the path fromthe content transmitting endpoint (CTEP) toward a plurality of contentreceiving endpoints (CREPs), directly or via one or more MCUs, reducesthe quality of the presented content. Further, the resolution of thepresented content is the resolution of the video image (CIF, SD, HD 720,HD 1080, for example), which is lower than the resolution of contentthat may be presented by using the original file format, which utilizesthe resolution of the screen, for example. The resolution for CIF is352×288; the resolution for Standard Definition (SD) is 704×576; theresolution for high definition (HD) 720 is 1280×720; the resolution forHD 1080 is 1920×1080. Furthermore, associating the content as compressedvideo with the compressed video image reduces the bit rate that may beallocated for carrying the compressed video image, thus reduces thequality of the video images.

The above-described deficiencies of handling content invideoconferencing are not intended to limit the scope of the inventiveconcepts of the present disclosure in any manner. The disclosure isdirected to a novel technique for handling content in videoconferencing.The new technique may handle the content by its original application.Other embodiments of the present disclosure converts the content fromits original file format into a popular presentation file format such asPDF, slide deck, spreadsheet, etc. and handling the content by thepopular presentation application. In the following description, theclaims, and the drawings the term “original application,” “originalformat,” and “original file format” may be used interchangeably.

An example embodiment of a videoconferencing system capable of sendingoriginal application content may comprise a CTEP and a CREP. The CTEPmay be associated with a conferee's computer that is used as the sourceof the presented content. The conferee's computer (CC) may be a personalcomputer, a laptop, a notebook, tablet, a smart phone, or any othercomputing device with data communication capabilities. In someembodiment the conferee's computer and the CTEP may be included in thesame device. In some embodiments of the system, the content may bedelivered from a CTEP to a plurality of CREPs via an intermediate node.The intermediate node may be an MCU or a media relay MCU (MRM).

An MRM is another conference controlling entity that may be located in anode of a network, in a terminal, or elsewhere. The MRM may receiveseveral media channels from access ports and according to certaincriteria may relay them to connected channels via other ports. A readerwho wishes to learn more about an MRM is invited to read U.S. Pat. No.8,228,363, which is incorporated herein by reference in its entirety forall purposes. In alternate embodiments a SIP server, which is capable ofestablishing real time video conferencing session between two terminals,may be used as an intermediate node.

An example of a CTEP may be configured to comprise a contenttransmitting module (CTM). An example of CTM may be capable tocommunicate with an associated conferee's computer over an IP connectionor a local area network (LAN), for example. When a conferee wants toshare a content file with the other conferees that participate in thevideoconferencing session, the conferee, by using the CC, may set aconnection with the CTM at the associated endpoint. The connection maybe an IP connection over the Internet or an Intranet. In otherembodiments, the CC and the CTEP may be connected over a LAN and theconnection may be based on the communication protocol used over the LAN,Ethernet protocol for example.

Upon establishing the connection between the CC and the CTEP, a contenttransmitting client agent (CTCA) may be loaded to the CC. The CTCA maybe loaded from the CC memory device (a disc for example). In otherembodiments, the CTCA may be downloaded from the CTEP to the CC. TheCTCA may instruct the conferee to select the requested content file andto open it by using similar application to the one that was used tocreate the file. An original application may be a spreadsheet reader,such an Excel for example, presentation reader such as PowerPoint forexample, Portable Document Format (PDF) reader application, etc. Whenthe content file was selected, the CTCA may be adapted to fetch the filefrom the CC memory device and send it toward the CTEP. Sending thecontent file may be offline via an email, for example. Alternatively,the content file may be sent online over a connection that wasestablished between the CC and the CTEP. An example of CTCA may comprisea plurality of application program interfaces (APIs), an API for eachpresentation application, an API for a PDF reader, an API for a slidepresentation application such as Microsoft POWERPOINT, an applicationfor a spreadsheet application such as Microsoft EXCEL®, etc. A PDFreader may be an ACROBAT® Reader application. (ACROBAT is a registeredtrademark of Adobe Inc.; POWERPOINT and EXCEL are registered trademarksof Microsoft Corporation.)

Yet in some embodiments, in parallel or in sequence to sending thecontent file, the CTCA may be adapted to collect, by using the relevantAPI, control signals that are used by the conferee while presenting thecontent on the CC. Control signals such as: page up, down, next page,markers, the location of the cursor, etc. The collected control signalsmay be transmitted toward the CTM at the CTEP and from the CREP to besent toward a CREP or an MCU. Further, in some embodiments the API maycomprise a section that is configured to follow user's activity on thepresented content. The API may communicate with the operating system ofthe CC and collect signals from drivers of the human-interfaces devicessuch as a mouse, a keyboard, a touch screen driver, etc. The obtainedsignals may be converted to the control signals that may be used thesystem.

The CTM may be adapted to establish an additional connection forcarrying the content in its original format (a PDF file, a PowerPointdeck, an Excel spreadsheet, etc.) and the collected control signals. Theadditional connection may be based on real-time-transport protocol (RTP)and real-time-transport-control protocol (RTCP). The additionalconnection may be between a CTM at a CTEP and a content-receiving module(CRM) at a CREP in case of a point-to-point (P2P) session. In case ofmultipoint conferencing, the additional connection may be between a CTMat a CTEP and an MCU or an MRM.

The CRM may comprise a plurality of APIs, one per each application. Byusing the appropriate API, the CRM may be adapted to obtain the contentfile in its origin format, invoke the appropriate application in theRCEP, and instruct the invoked application to present the content basedon the received control signals. The content may be presented on asecond display unit that is associated with a first display unit thatpresents the video image. In some CREP in which a single screen is used,a portion of the screen may be allocated for presenting the content andthe rest of the screen may be used for presenting the video image of thepresented conferees. Further, in some embodiments in which the APIbetween the CRM and the relevant application is limited, in such a case,the CRM may be configured to add a layer on the display of the content.The layer may be used for presenting controls that cannot be implementedby the API, control such as but not limited to markers, pointers, etc.Further, in some embodiments the API may comprise a section that isconfigured to follow user's activity on the presented content. The APImay communicate with the operating system of the CC and collect signalsfrom an appropriate driver such as the mouse, the keyboard, the touchscreen driver, etc. The obtained signals may be converted to the controlsignals that may be used at the CREP. Adding a layer on the video may besimilar to adding other graphic layer above the video image that is wellused in video conferencing systems. A reader who wishes to learn moreabout adding a layer above the video image is invited to read a USpatent number U.S. Pat. No. 7,542,068, the content of which isincorporate herein by reference.

Some limited CREPs do not have plurality applications that may be usedfor presenting content in its original file format. In case that such alimited CREP participates in a video conferencing that involvesdelivering of content in its original file format, then a transformationis needed for transforming the content from its original format into aformat that may be used by the limited CREP. CREP. In one embodiment, anMCU may be adapted to convert the received content from the CTEP, in itsoriginal format with the control signals, convert it to a video image,and present the video image of the content with the control signals, asa video image in a segment of the continuous presence video image, as itis done today.

In alternate embodiment of and MCU, the MCU may communicate with thelimited CREP for determining whether the CREP has at least one popularpresentation application, such as but not limited to Acrobat,PowerPoint, HTML, for example. In case that the CREP has one of thoseapplications, the MCU may be configured to convert the content from itsoriginal format into the one that may be implemented by the CREP. Insome embodiments, the CTEP may convert the file into PDF, for example.

Examples of content delivering system may be configured to operate inmedia relay videoconferencing in which an MRM and MREs are used. Acontent transmitting media relay endpoint (CTMRE) may be adapted toinclude a CTM, which may be similar to a CTM of a CTEP. In addition, anexample of an MRM may be configured to receive, over a dedicatedconnection, the content from the CTM that is located at the CTMRE. Thecontent is transmitted in its original format as it is disclosed abovein conjunction with an MCU. The MRM may be configured to relay thereceived content and control signals to one or more content receivingmedia relay endpoints (CRMREs). An example of a CRMRE may comprise aCRM, which may be similar to the CRM of a CREP. The CRM may receive thecontent in its original format with the control signals and process itin a similar way that is done in the CREP. The content may be presentedon a second display unit or may share a single display unit of the CRMREwith the video.

FIG. 1 illustrates a block diagram with relevant elements of a portionof a multimedia multipoint conferencing system 100 according to oneembodiment of a videoconferencing system capable of sending originalapplication content. System 100 may comprise a network 110, connectingone or more MCUs or MRMs 120 a-c, a plurality of CREPs 133 and a CTEP131. The CTEP 131 may be associated with the CC 140. In some embodimentsin which network 110 includes a plurality of MCU/MRMs 120, a virtual MCU(not shown) may be used for controlling the plurality of MCUs 120. Moreinformation on a virtual MCU may be found in U.S. Pat. No. 7,174,365,which is incorporated herein by reference in its entirety for allpurposes. In some embodiments of system 100, one of the MCUs 120 mayperform the functionality of the virtual MCU and may control the rest ofthe MCUs 120. An endpoint 131 or 133 (which may be referred to as aterminal) is an entity on the network, capable of providing andreceiving real-time, two-way content, audio, and/or visual communicationwith other endpoints or with the MCU 120. An endpoint 131 or 133 may beimplemented by a computer; a PDA (personal digital assistant); a cellphone; a tablet, a TV set with a microphone and a camera, etc.

In addition to common operation of a video conferencing endpoint or amedia relay endpoint, an example of a CTEP 131 may be configured tohandle content in its original format. An example of CTEP 131 may beconfigured to communicate with an associated CC 140 over an IPconnection 145 or a LAN, for example. When a conferee that is associatedwith CTEP 131 is willing to share a content file with the otherconferees that participate in the videoconferencing session, theconferee, by using the CC 140, may make a connection 145 with the CTEP131. The connection may be an IP connection over the Internet or anIntranet. In other embodiments, the CC 140 and the CTEP 131 connection145 may be over a LAN and the connection may be based on thecommunication protocol used over the LAN, for example an Ethernetprotocol.

The CC 140 may be a personal computer, a laptop, a notebook, a tablet, asmart phone or any other computing device with data communicationcapabilities. In one embodiment, the CC 140 and the CTEP 131 may beembedded in the same device. In such an embodiment, the connection 145may be a shared memory located at the same device, for example.

Upon establishing the connection 145 between the CC 140 and the CTEP131, a CTCA may be installed or otherwise loaded on the CC 140. The CC140 with the CTCA may be configured to perform actions comprisingactions that cause the CC 140 to instruct the conferee to select therequested content file and to open it by using an appropriate viewerapplication that may process and display the content in its originalfile format. A viewer application may be a spreadsheet application, suchMicrosoft Excel for example, a presentation reader such as MicrosoftPowerPoint, a PDF viewer such as Adobe Reader, etc. When the contentfile is selected, the CC 140 may be adapted to fetch the file from a CC140 memory device (not shown in the drawings) and send it toward theCTEP 131. Sending the content file may be offline, for example via anemail. Alternatively, the content file may be sent online over theconnection 145.

One embodiment of a CC 140 may comprise a plurality of transmittingapplication program interfaces (tAPIs), a tAPI for each viewerapplication, e.g., a tAPI for a PDF viewer, a tAPI for a PowerPointviewer, etc. An example PDF viewer is ACROBAT® Reader. (ACROBAT is aregistered trademark of Adobe Inc.) The relevant tAPI may collect theuser activities on the presented file and transfer information regardingthose activities as control signals toward the CREP 133 directly (for aP2P session), or via an intermediate node, such as an MCU/MRM 120 a-cfor example, for a multipoint videoconferencing session. The useractivity may include scrolling through the content, marking an area ofthe content, pointing at an area of the content, moving a cursor on thecontent, etc.

The CTEP 131 may be configured to establish an additional connection 135between the CTEP 131 and the MCU or MRM 120, or directly with a CREP 133for carrying the content in its original format and the collectedcontrol signals. The additional connection 135 may be based on areal-time-transport protocol (RTP) and a real-time-transport-controlprotocol (RTCP). More information on the operation of CC 140 and CTEP131 is disclosed below in conjunction with FIG. 2 and FIG. 5.

One embodiment of a CREP 133 may comprise one or more applicationreaders or viewers that may present and display content in its originalformats. The application viewers may include PowerPoint viewers, PDFreaders, spreadsheet viewers, etc. Each application may be associatedwith a receiving API (rAPI). The rAPI may be configured to receive thecollected control signals that were sent from the CC 140 via the CTEP131, process those control signals and employ those instructions on theapplication reader that is used to display the content file in itsoriginal format. Thus, the content that is currently presented on adisplay unit associated with the CREP 133 follows the presentationdisplayed on the CC 140.

The content may be presented on a second display unit associated withthe CREP 133 that is associated with a first display unit, whichpresents the video image. In some embodiments of CREP 133, in which asingle screen is used, a portion of the screen may be allocated forpresenting the content and the rest of the screen may be used forpresenting the video image of the presented conferees. Further, in someembodiments, in which the rAPI is limited, the CREP 133 may beconfigured to add a layer on the displayed content. The layer may beused for presenting effects or the results of the user's activity thatcannot be presented by the API, user's activities such as but notlimited to markers, pointers, etc.

In some embodiments, the tAPI may comprise a section that is configuredto follow a user's activity on the presented content. The tAPI maycommunicate with the operating system of the CC 140 and collect signalsfrom an appropriate driver such as the mouse, the keyboard, the touchscreen driver, etc. The obtained signals may be converted to the controlsignals that may be used at the CREP 133. In a similar way the rAPI maybe configured to include instruction that may cause a processor in theCREP to obtain the control signal process them and present the useractivity on the added layer. Adding a layer on the presented content maybe similar to adding other graphic layer above the video image that iswell used in video conferencing systems. More information on theoperation of CREP 133 is disclosed below in conjunction with FIG. 4 andFIG. 7.

An MCU or MRM 120 may be used for managing the videoconference sessions.In addition to common operation of an MCU or an MRM for managing avideoconferencing session between a plurality of endpoints or mediarelay endpoints, the MCU or MRM 120 may be configured to relay contentfiles in their original format as well as the API control signals fromthe CTEP 131 toward one or more CREPs 133. More information on theoperation of an intermediate entity such as an MCU or an MRM 120 isdisclosed below in conjunction with FIG. 3 and FIG. 6.

FIG. 2 illustrates a simplified block diagram with relevant elements ofa content transmitting system 200. The system 200 may comprise a CC 210and a CTEP 240 according to one embodiment. The CC 210 may be a personalcomputer, a laptop, a notebook, tablet, a smart phone, or any othercomputing device with data communication capabilities. In oneembodiment, the CC 210 and the CTEP 240 may be included in the samedevice. Among other components of a computing device, a CC 210 maycomprise one or more processors, computer readable media such as aread/write hard disc, CDROM, Flash memory, ROM, or other memory orstorage, etc. (not shown in the drawings) Software of a logical modulemay be embodied on one of the computer readable media. In order toexecute a certain task, a software program may be loaded to anappropriate processor as needed.

An example of CC 210 may comprise one or more applications 220, 222, and224 that may be used for presenting content. CC 210 may include apresentation reader application 220, a PDF reader application 222,and/or spreadsheet reader application 224, for example. In addition, theCC 210 may comprise a network interface (NI) module 212 that is used fordata communication with other computing devices. The data communicationmay be over an IP network, a LAN, etc. In an embodiment in which the CC210 and the CTEP 240 are embedded in a single device, the NI 212 may bea shared memory or an internal bus of the single device.

In addition to common logical modules that are included in the CC 210,an additional logical module, a content transmitting client agent (CTCA)214 logical module, may be loaded to the CC 210. Loading the CTCA 214may be done by the conferee that wishes to present the content to theother participants in the videoconferencing. Loading the CTCA 214 to aprocessor of CC 210 may be done from one of the memory devices (notshown in the drawings) of the CC 210. Alternately, the CTCA 214 may bedownloaded from the CTEP 240, after establishing the connection betweenthe two units. An embodiment of a CTCA 214 may comprise one or moretransmitting application program interface (tAPI) modules 230, 232, and234. Each tAPI module may be associated with its related application.For example, slide deck tAPI 230 is associated with a slide presentationreader application 220, PDF tAPI 232 is associated with PDF readerapplication 222, and spreadsheet reader tAPI 234 is associated withspreadsheet reader application 224, etc.

In addition to the tAPI modules 230, 232, and 234, an example of CTCA214 may comprise a CTCA manager (CTCAM) 216. An embodiment of the CTCAM216 may be configured to perform actions comprising actions that causethe CTCA 214 to instruct the NI 212 to create an additionalcommunication link over connection 218 with the CTEP 240. The additionalcommunication link may be used for transferring the content in itsoriginal format and the tAPI-instructions for restoring the presentingconferee's activity on the presented content. Such activity may includemarking an area on a presented slide. The communication over thecommunication link 218 may be based on RTP and RTCP, in someembodiments. In alternate embodiments, the communication over thecommunication link 218 may be based on asynchronous communicationprotocols, such as XML or AJAX.

According to the type of a selected content file, CTCAM 216 may instructthe relevant tAPI module, 230, 232, or 234, to fetch the selected filefrom the CC 210 memory device and transfer a copy of the content file inits original format over the connection 218 toward the CTEP 240. In someembodiments, transferring the content file toward an MCU 120 or a CREP133 may be done offline by an email.

In some embodiments, each fetched content file may be converted by CTCAM216 into a popular type format, such as a PDF format. PDF is a verypopular file format. Many computing devices, as well as the CREP 133,may have a PDF reader application that may be used for presenting thetransferred content file.

After transferring the content file, the CTCAM 216 may prompt theconferee to start the content presentation. Next the relevant tAPI maybe instructed to open the fetched content file, and to start to obtaindata regarding the conferee's activity. The data regarding the activitymay be transferred by the relevant tAPI modules 230-234 toward the CTCAM216 that convert them into instructions that are sent via the NI module212, the CTEP 240, and the MCU 120 toward one or more CREPs 133, wherethe received instructions may be converted into the presentation formatand be displayed on a display unit of the CREP 133. The CTCA 214 may beactive as long as the content presentation session is active. At the endof the content presentation session, the CTCA 214 may be released.

Referring now to the CTEP 240, among other elements of a videoconferencing endpoint, an example of a CTEP 240 may comprise a contenttransmitting module (CTM) 244 and two NI modules 242 and 246. NIa 242may be used for data communication with CC 210. The data communicationmay be over an IP network, a LAN, etc. In an embodiment in which the CC210 and the CTEP 240 are embedded in a single device, the NIa 242 may bea shared memory or an internal bus of the single device. The second NIb246 may be used for data communication with an MCU 120 or directly witha CREP 133, if the communication session is a P2P session. The datacommunication may be over an IP network. The communication over the twoNI modules 242 and 246 may be based on an asynchronous protocol, suchas, but not limited to, RTP and RTCP.

An example of a CTM 244 may be configured to communicate with the CTCA214 via NIa 242, communication link 218, and NI 212. When a conferee iswilling to present a content file to the other conferees thatparticipate in a videoconferencing session, the conferee, by using abrowser application, for example, at CC 210, may create a connectionwith the CTM 244 at the associated CTEP 240. The connection may be an IPconnection over the Internet or an Intranet. In other embodiments, CTCA214 may be loaded from any type of computer readable media such asCDROM, Flash memory, etc.

CTM 244 may be a processor that executes a server application, forexample a content transferring gateway application. The CTM 244 mayserve as a gateway between the CC 210 and an MCU 120 or a CREP 133. Inone embodiment, upon receiving a request from the browser application ofCC 210 for fetching the software file of CTCA 214, CTM 244 may beconfigured to fetch the CTCA 214 software file from a memory device (notshown in the figures) of CTEP 240 and download it to CC 210. Next CTM244 may establish an additional connection via NIb 246 to an MCU 120 orCREP 133, if using a point to point (P2P) session. The additionalconnection may be used for carrying the content in its original formatand the collected control signals toward its destination.

During the ongoing content presentation, CTM 244 may be used as a relaythat receives packets from CTCA 214 that carry payload that includesinformation regarding the activities of the presenting conferee on thepresented content, such as, but not limited to, page-up, page-down,marker, etc. The CTM 244 may parse those packets, retrieve the payload,and send the payload in a new packet to the IP address of the relevantMCU 120 or a CREP 133 (in a P2P session). More information on theoperation of CC 210 and CTEP 240 is disclosed below in conjunction withFIG. 5.

FIG. FIG. 3 schematically illustrates a simplified block diagram withrelevant elements of an example embodiment of an MCU 300 serving as anintermediate control unit that is configured to operate in avideoconferencing system capable of sending original applicationcontent. An example embodiment of MCU 300 may comprise one or moreprocessors, computer readable medium such as a read/write hard disc,CDROM, Flash memory, ROM, or other memory or storage devices, etc.Software of a logical module may be embodied on one of the computerreadable medium. In order to execute a certain task, a software programmay be loaded to an appropriate processor as needed. Among other logicalmodules of a common MCU, MCU 300 may comprise an NI module 310, one ormore video module 320 (one per each active conference, for example), acontrol module 330 and one or more MCU original application contentmodules (MOACM) 340 (one per each active conference, for example). Othertypes of intermediate control units may be used, which may not be MCUs.

The NI module 310 may receive multimedia communication from a pluralityof endpoints 131, 133 via networks 110. NI 310 may process thecommunication according to one or more communication standards such as,but not limited to, H.320, H.323, SIP, etc. NI 310 may also process thecommunication according to one or more compression standards such as,but not limited to, H.261, H.263, H.264, G711, G722, MPEG, etc. NI 310may receive and transmit control and data information to and from otherMCUs and endpoints. More information concerning the communicationbetween endpoints and the MCU over network 110 and informationdescribing signaling, control, compression, and creating a video callmay be found in the international telecommunication union (ITU)standards H.320, H.321, H.323, H.261, H.263, H.264 G711, G722, and MPEG,etc. In addition, NI 310 is configured to receive from a CTEP 240packets carrying a presentation file in its original file format as wellas packets that carry payload with information regarding the activity ofthe conferee on the presented content.

NI module 310 may multiplex/de-multiplex the different signals, mediaand/or “signaling and control” that are communicated between theendpoints 131, 133 and the MCU 300. The compressed audio signal may betransferred to and from an audio module, which is not shown in thefigures. The compressed video signal may be transferred to and from thevideo module 320. The “control and signaling” signals may be transferredto and from control module 330. Packets that were obtained from a CTEP240 and carry content related data in an original file format of thecontent may be transferred toward the MOACM 340. Relayed packetsreceived from the MOACM 340 that carry payload with data related tocontent in its original format may be transferred by NI 310 toward theappropriate CREPs 133. The data related to content may include data ofthe content file or information regarding the activity of the presentingconferee on the presented content.

Video module 320 may receive compressed video streams from the pluralityof endpoints 131, 133, which are sent toward the MCU 300 via network 110and processed by NI 310. Video module 320 may create one or morecompressed continuous presence video images according to one or morelayouts that are associated with one or more conferences currently beingconducted by the MCU 300. A video module 320 according to one embodimentmay have a plurality of input modules 321, a plurality of output modules325, and a video common interface 323. Each input module 321 may beassociated with an endpoint. Each output module 325 may be associatedwith one or more endpoints.

An input module 321 may be associated with an endpoint and may processcompressed video images received from its associated endpoint. Adecoder, not shown in the figure, may receive compressed video from anassociated endpoint and may decode the compressed video into decodedvideo data. The decoded information may be stored in a decoder framememory from which it is transferred toward one or more output modules325 via common interface 323.

Among other elements, an output module 325 may include an editor module327 and an encoder module 329. Editor module 327 may get decoded data ofselected video images from the common interface 323 to be composed intoa continuous presence video image to be transferred toward a receivingendpoint. The editor 327 may scale, crop, and place the video data ofeach conferee into an editor frame memory according to the location andthe size of the image in the layout associated with the composed videoof the continuous presence image. If one of the CREPs 133 cannot receivecontent in its original format, the content may be converted into avideo image by a content to video converter (CTVC) 343 and the videoimage of the content may be sent toward the common interface 323.

If the CREP 133 cannot process content in its original format and mustpresent the content in a segment of a continuous presence video imagewith the video images of presented conferees, an Editor 327, which isembodied in the relevant output module 325, may obtain the video imageof the content from the common interface 323 and scale it into anappropriate size of the relevant segment in the continuous presencevideo image. The encoder 329 may obtain the decoded continuous presencevideo image with the content in one of the segments, compress it byusing an appropriate compression standard, and send the compressedcontinuous presence video image toward the relevant one or more CREPs133 via NI 310.

Alternatively, if the CREP 133 cannot process content in its originalformat but may present the content as video switching on a separatedisplay unit, then an Editor 327, which is embodied in the relevantoutput module 325, may obtain the video image of the content from thecommon interface 323 and scale it into an appropriate resolution as itis required by the separate display unit, and the scaled video image ofthe content may be transferred toward the encoder 329. The encoder 329may obtain the scaled video image of the content and compress it byusing an appropriate compression standard. The compressed video image ofthe content may be sent toward the relevant one or more CREPs 133 via NI310. The common interface 323 may comprise a TDM bus, a shared memory,or any common bus that may be used in a computing device.

If the intermediate node comprises an MRM instead of an MCU, the exampleembodiment of the MRM may omit the video module 320 and the CTVC 343.The MRM may just relay the content packets via a content distributionmodule (CDM) module 342.

An example of MOACM 340 may comprise a CDM 342 and a CTVC 343. In someembodiment of MOACM 340 the allocation of CDM 342 and/or CTVC 343depends on the content capabilities of the CREPs that participant in acurrent conference. A CDM 342 may be allocated if at least one CREP 133may accept content in its original file format and a CTVC 343 may beallocated if at least one CREP 133 cannot accept content in its originalfile format. An example of a CDM 342 may comprise a cyclic buffer thatstores received packets that carry content in the original file formator carry information about the activity of the user on the presentedcontent. The received packets were sent from a CTEP via the NI 310.Further, an embodiment of a CDM 342 may be configured to fetch thestored packets from the cyclic buffer, one after the other, anddistribute them toward one or more CREPs 133 via the NI 310. Inaddition, when MOACM 340 comprises a CTVC 343, then the CDM 342 may befurther configured to distribute the fetched packets also toward theCTVC 343.

An example of a CTVC 343 may be configured to obtain packets from theCDM 342 that carry content in its original format and/or informationregarding the activity of the conferee on the presented content, in theconferees CC 210. The CTVC 343 converts the fetched data into a snapshotof the presentation image that is currently presented on the displayunit of CC 210, and transfers the created image of the snapshot towardthe video common interface 323. From the video common interface 323, thevideo image is fetched by one or more output modules 325 and from therethe compressed video image is transferred toward one or more CREPs thatoperate in the tradition way.

In order to convert the content into video image, CTVC 343 may compriseone or more content presentation readers and a CRM that operates in asimilar way to a CRM 420 of a CREP 400 that is disclosed below inconjunction to FIG. 4.

Control module 330 may be a logical unit that controls the operation ofthe MCU 300. In addition to common operation of a typical MCU, MCU 300is capable of additional functionality as result of having the controlmodule 330. Control module 330 may include anoriginal-application-content controller (OACC) 332. During the set upprocess of a content session in a conference an example of OACC 332 maycommunicate with the CTEP and the one or more CREPs 133 in order todetermine whether content may be transmitted in its original format andwhether a CDM 342 and/or a CTVC 343 module are needed and be allocatedaccordingly. The OACC 332 may receive information and updates via the NI310. Such information may include, but is not limited to: the number ofsites that will participate in the conference call, which site hasdeparted, which sites have been added, which site may process contentreceived in its original file format, and so on.

The OACC 332 may instruct the NI 310 to set connections to carry thecontent in its original format with one or more CREPs 133, associatebetween the CDM 342 and the NI 310, allocated video resources in thevideo module 320 (if needed), for handling the content in the traditionway and associate the CTVC 343 with the allocated video resources. Upondetermining that the content presentation session was terminated, OACC332 may be adapted to release the allocated resources. More informationabout the operation of MCU 300 is disclosed below in conjunction withFIG. 6.

FIG. 4 illustrates a simplified block diagram with relevant elements ofa CREP 400. An embodiment of the CREP 400 may comprise a display module450, one or more applications 432, 436, and 442 that may be used forpresenting content, such as, but not limited to: a presentation readerapplication 432; a PDF reader application 436, such as a 3-Heights™ PDFViewer; and/or spreadsheet reader application 442, for example. Inaddition CREP 400 may comprise an NI module 410 that is used for datacommunication with other computing devices. The data communication maybe over an IP network, a LAN, etc. The display module may include asingle screen. In such an embodiment of a CREP 400, a portion of thescreen may be allocated for presenting the content (after beingprocessed by the appropriate application 432, 436, or 442, for example)and the rest of the screen may be used for presenting the continuouspresence video image of the presented conferees. In other embodiments,the display module may comprise two screens. One may be used to displaythe continuous presence video image and the other may be used forpresenting the content after being processed by the appropriateapplication 432, 436, or 442.

In addition to common logical modules that are included in a commonendpoint, additional logical modules are added in order to presentcontent received in its original format. The additional modules mayinclude a CRM 420. An example of a CRM 420 may comprise one or more rAPImodules 430, 434 and 440, for example. The rAPI may be similar to APIcodes that are associated with presentation application readers that areembedded in “Open-Office” software suite. Each rAPI module may beassociated with its relevant application. For example, a slide deck rAPI430 is associated with a slide presentation reader application 432, PDFrAPI 434 is associated with PDF reader application 436, and spreadsheetrAPI 440 is associated with spreadsheet reader application 442. By usingthe appropriate rAPI the CRM 420 may be adapted to obtain the contentfile in its original format, invoke the appropriate application, andinstruct the invoked application to present the content in a similarfile view as the content presented over the display unit of the CC 210,based on the received control signals.

In addition to the rAPI modules 430, 434 and/or 440, an example of CRM420 may comprise a CRM manager (CRMM) 422. An example CRMM 422 may beconfigured to perform actions comprising actions that cause the CRM 420to instruct the NI 410 to set an additional communication link with anMCU 120. The additional communication link may be used for receiving thecontent in its original format and information regarding the activity ofthe presenting conferee on the presented content. This information andthe content may be transferred toward the appropriate rAPI thataccordingly instruct the relevant application reader to restore theimage (view) of the content presented on the screen of the CC 210. Thepresenting conferee's activity may be such as, but not limited to,marking an area on a presented slide, page-up, page-down, etc. Thecommunication with the MCU 120 may be based on RTP and RTCP, forexample.

Further, in some embodiments in which the rAPIs 430, 434 and/or 440 arelimited, the CRM 420 may be configured to add a layer on the display ofthe content. The layer may be used for presenting user activity thatcannot be presented by the rAPI, activity such as but not limited tomarkers, pointers, circles, etc. Adding a layer on the video may besimilar to adding other graphic layers above the video image that iscommonly used in video conferencing systems. More information on theoperation of an example of CREP is described below in conjunction withFIG. 7.

FIG. 5 is a flowchart illustrating relevant actions of a process 500 fortransmitting content that may be implemented by a CTM 244 in a CTEP 240,for example. Process 500 may be initiated in block 502 when a confereethat is associated with the CTEP 240 (the presenting conferee) iswilling to present content and informs a processor of the CTEP 240 aboutthe conferee's request to present the content. As a result, a CTMprogram 504 may be loaded to the processor from a memory device of CTEP240, for implementing the actions that are needed for employing theprocess 500.

At block 506 CRM 244 may send a signaling and control indication towardan MCU 120 asking the MCU 300 whether an original format contentpresentation session may be established. If 510 the MCU 300 rejects therequest, then at block 512 the common content delivery task may beinvoked for transmitting the content as a video image in the traditionalway and process 500 may be terminated. A rejection may be sent from anMCU 300 that was not configured to handle a content presentation in itsoriginal format. In some embodiments, such as a P2P videoconferencingfor example, the MCU 300 may be replaced by a CREP 133.

If in block 510 the MCU 300 agrees to handle the content in the originalformat, then at block 514 process 500 may prompt the presenting confereeto send the content in its original format from the CC 210. In additiona hyper-link may be presented to the conferee informing the confereeabout an IP address from which a CTCA 214 may be downloaded to the CC210. Then process 500 may wait in block 520 for receiving a request fromthe CC 210 to download the CTCA logical module 214. Upon receiving thedownload request, CTM 244 may fetch the CTCA module from the CTEP 240memory device and download it to the CC 210 in block 522.

Next, process 500 may establish in block 524 a communication channelwith the CTCA 214 for obtaining packets that carry the content file aswell as tAPI information regarding the operation of the presentingconferee. A second communication channel may be established in block 524with the MOACM 340 at the MCU 300 for transferring the content and theinformation about the activity of the presenting conferee on thepresented content. The communication channel may be based on RTP andRTCP, for example. In some embodiments, the content file may be sent asan email from the CTCA 214 toward the MCU 300, while the tAPIinformation may be sent over the RTP and the RTCP connection.

Next at block 530, process 500 may wait for receiving packets over theestablished connection via NIa 242. Each received packet is relayed inblock 536 via NIb 246 toward the MOACM 340 at the MCU 300 and process500 may check in block 540 whether an indication of end of contentsession is received from CTCA 214. If not, process 500 returns to block530 for processing the next received packet. If the end of contentsession indication is received, then the relevant resources may bereleased and process 500 may be terminated.

FIG. 6 illustrates a flowchart with relevant actions of a process 600for content receiving and transmitting that may be implemented by an MCU300 according to one embodiment. Process 600 may be initiated 602 aftercontrol module 330 obtains the signal and control indication that wassent from the CTEP 240 at block 506 requesting the MCU 300 to establisha content session in the original format. After approving the request ofthe CTEP 240, an OACC module 332 may be allocated and an OACC programmay be loaded in block 604 from a memory device of MCU 300 to aprocessor of the MCU 300 that will handle the content session.

At block 606, OACC 332 may instruct the NI 310 to send a signaling andcontrol indication to each one of the CREPs 400 for checking whether theCREP 400 may process content in its original format. After collectingthe responses from the CREPs 400, a decision may be made in block 610whether content in its original format may be used. If so, at least oneCREP 400 may process the content in the original format. Alternatively,if none of the CREPs 400 may process content in the original format,thus the content in the original format cannot be used, then the CTEP240 may be requested in block 612 to send the content in the traditionalway of sharing content in a video conference and OACC 332 may invoke thecommon content delivery task for receiving and sending content in thetraditional way. Next the resources of the OACC 332 may be released andprocess 600 may be terminated.

If the decision is made in block 610 the content in its original formatmay be used, then OACC 332 may allocate computing resources and storageresources for the MOACM 340 and an MOACM program may be loaded in block614 from a memory device of MCU 300 to the allocated computing resourcesof MOACM 340 that will handle the content session. A register R may bereset. Register R may be used for indicating that a CTVC 343 has beenalready allocated. Next, a loop may be initiated between block 616 andblock 630, wherein each cycle in the loop is associated with a CREP 400.

At block 616, the content capabilities of the next CREP 400 is checkedin order to determine whether the CREP 400 may process content in itsoriginal format or it needs the content as a video stream. If in block620 the CREP 400 cannot process content in its original format andrequires that the content will be converted to a video stream, then thevalue of register “R” is checked in block 624. If the value is true(R=1), then process 600 proceeds to block 628. If block 624 determinesthe value is false (R=0), then in block 626, resources for convertingthe content from its original format into video (CTVC 343) may beallocated to MOACM 340. The allocation may comprise loading anappropriate application that may process the original format, forexample, a PDF reader. An rAPI may be loaded too. The rAPI may translatethe presenting conferee activity on the currently presented content.After allocating the CTVC 343 resources, the register “R” may be set totrue (R=1) in block 626.

Next, OACC 332 may request in block 628 the control module 330 toallocate video resources and NI resources for handling the video streamof the content that is targeted toward that CREP 400. The videoresources depend on the capabilities of that CREP 400. If the CREP 400uses a separate display unit for presenting the video stream of thecontent the video resources is just an encoder that matches thecompression needs of the CREP 400. The NI resources may comprise acommunication channel based on RTP for carrying the content and an RTCPchannel for managing the traffic over the RTP channel. If the CREP 400displays the content in a segment in a continuous presence video image,then the editor 327 of the appropriate output module 325 may be informedin block 628 about the content segment and the relevant section of thecommon interface 323 that is allocated for the video stream of thecontent. The section in the common interface 323 may be a time slot,where the common interface 323 is a TDM bus, or interval of addresses,when the common interface 323 is a shared memory, etc. There is no needfor NI resources for such a case. Then a decision is made in block 630whether an additional CREP 400 exists. If yes, then process 600 returnsto block 616 for handling the next CREP 400.

Returning now to block 620, if the CREP 400 may process content in itsoriginal format, then at block 622 the NI module 310 may be instructedto establish an RTP channel and an RTCP channel with that CREP 400.Next, a content packet relay module may be allocated in block 622, inMOACM 340. The content packet relay module may be instructed to fetchpackets carrying content or tAPI information from the cyclic buffer ofthe CDM 342, adapt the header of the packets according to the IP addressand port of the CREP 400, and transfer the packets, one after the other,toward the CREP 400 via the NI 310 and the two allocated channels, andprocess 600 may proceed to block 630.

If in block 630 there are no additional CREPs 400, then OACC 332 mayinstruct the CTEP 240 to start sending packets that carry content in itsoriginal format and packets that carry tAPI information to be relayedtoward the CREP 400 and process 600 may wait in block 634 to receive anend of content session indication. in block 636, upon receiving the endof content indication, process 600 may release the resources that wereallocated for handing the content session and terminate.

FIG. 7 illustrates a flowchart with relevant actions of a process 700for handling content in its original format by a CREP 400 according toone embodiment. Process 700 may be initiated in block 702 after acontrol module (not shown) of the CREP 400 obtains a signal and controlindication from an MCU 300 requesting to establish a content session inan original file format with the CREP 400. After approving the requestof the MCU 300, resources for a CRMM 422 may be allocated and a CRMMprogram may be loaded in block 704 from a memory device of CREP 400 to aprocessor of the CREP 400 that will handle the content session.

At block 706, based on the type of the original file format of thecontent, CRMM 422 may allocate computing and storage resources for theappropriate reader application (432, 436, and 442) and its associatedrAPI (430, 434, or 440, respectively). Then, the reader application andthe appropriated rAPI may be invoked from a memory device (not shown) ofthe CREP 400. The rAPI may be adapted to accept a payload of packetsreceived from the CTEP 240 via the MCU 300. The payload may comprisedata of the content file and information about the activity of thepresenting conferee on the presented content, such as page-up,page-down, marking, etc. The content and the activity information may beprocessed into a format that the application reader may use in order topresent the content with the presenting conferee's activity on a displayunit 450 of the CREP 400.

In some embodiments, in which the tAPI or the rAPI have limitedfunctionality, the rAPI may be configured to place a layer on thepresented content. In such a case, the tAPI may be configured to followthe user's activity on the presented content. The tAPI may communicatewith the operating system of the CC 140 and collect signals fromappropriate human-interface drivers such as the mouse, the keyboard, thetouch screen driver, etc. The obtained signals may be converted tocontrol signals that may be used at the CREP 400. In a similar way therAPI may be configured to include instruction that may cause a processorin the CREP 400 to obtain the control signals, process them, and presentthe user activity on the added layer.

At this point of time the CREP is ready and may wait at block 710 forobtaining packets carrying content and information about the conferee'sactivity. The received packet may be parsed in block 712 by the CRMM 422in order to determine in block 720 whether the received packet includesan end of content session indication. If found, CRMM 422 may stop thecontent presentation and release in block 722 the resources that wereallocated for handling the content in the CREP 400 and process 700 maybe terminated. If the received packet does not include an end of contentsession indication, then the content of the payload is transferred inblock 724 via the invoked rAPI toward the invoked application reader forfurther processing in order to present the content file view on thedisplay unit 450 with a similar appearance as the file view on thedisplay unit of the CC, and process 700 returns to block 710 forhandling the next packet.

It will be appreciated that the above-described apparatus, systems, andmethods may be varied in many ways, including changing the order ofsteps, and the exact implementation used. The described embodimentsinclude different features, not all of which are required in allembodiments of the present disclosure. Moreover, some embodiments of thepresent disclosure use only some of the features or possiblecombinations of the features. Different combinations of features notedin the described embodiments will occur to a person skilled in the art.Furthermore, some embodiments of the present disclosure may beimplemented by combination of features and elements that have beendescribed in association to different embodiments in the disclosure. Thescope of the invention is limited only by the following claims andequivalents thereof.

While certain embodiments have been described in details and shown inthe accompanying drawings, it is to be understood that such embodimentsare merely illustrative of and not devised without departing from thebasic scope thereof, which is determined by the claims that follow. Inthe appended claims, the terms “including” and “in which” are used asthe plain-English equivalents of the respective terms “comprising” and“wherein”.

1.
 1. A videoconferencing endpoint, comprising: a display unit; acontent receiving module, configured to receive presented content from acontent presenting endpoint in its original file format and associatedinformation regarding activity of a presenting conferee on the presentedcontent; and a presentation reader module configured to present on thedisplay unit similar presented content and the activity of thepresenting conferee on the presented content as the activity isdisplayed on a display unit of the content presenting endpoint.
 2. Thevideoconferencing endpoint of claim 1, wherein the activity of thepresenting conferee comprises marking an area of the presented content.3. The videoconferencing endpoint of claim 1, wherein the activity ofthe presenting conferee comprises pointing at an area of the presentedcontent.
 4. The videoconferencing endpoint of claim 1, wherein theactivity of the presenting conferee comprises scrolling through thecontent.
 5. The videoconferencing endpoint of claim 1, wherein thepresentation reader module comprises a portable document format reader.6. The videoconferencing endpoint of claim 1, wherein the presentationreader module comprises a spreadsheet reader.
 7. A method of presentingcontent in a videoconferencing endpoint, comprising: receiving presentedcontent in its original file format and associated information regardingactivity of a presenting conferee from a content presenting endpoint;and presenting similar presented content and the activity of thepresenting conferee on the presented content as the activity isdisplayed on a display unit of the content presenting endpoint.
 8. Themethod of claim 7, wherein the activity of the presenting confereecomprises marking an area of the content.
 9. The method of claim 7,wherein the activity of the presenting conferee comprises pointing at anarea of the content.
 10. The method of claim 7, wherein the activity ofthe presenting conferee comprises scrolling the content.
 11. The methodof claim 7, wherein the original file format is a portable documentformat.
 12. A videoconferencing endpoint, comprising: a contenttransmitting client agent, configured to: obtain a selected file ofpresented content in its original format; and collect associatedinformation regarding activity of a presenting conferee on the file ofpresented content; and a content transmitting module, configured totransmit the file of presented content toward a content receivingendpoint in its original file format and the associated information. 13.The videoconferencing endpoint of claim 12, wherein the activity of thepresenting conferee comprises marking an area of the presented content.14. The videoconferencing endpoint of claim 12, wherein the activity ofthe presenting conferee comprises pointing at an area of the presentedcontent.
 15. The videoconferencing endpoint of claim 12, wherein theactivity of the presenting conferee comprises scrolling through thecontent.
 16. The videoconferencing endpoint of claim 12, wherein contenttransmitting client agent comprises application programming interfacesfor a plurality of presentation applications.
 17. The videoconferencingendpoint of claim 12, wherein the content transmitting client agenttransmits the file of presented content in its original format and theassociated information to the content transmitting module over a localarea network.
 18. A method of presenting content in a videoconferencingendpoint, comprising: obtaining a selected file of presented content inits original file format; collecting associated information regardingactivity of a presenting conferee on the file of presented content; andtransmitting the file of presented content toward a content receivingendpoint in its original file format and the associated information. 19.The method of claim 18, wherein the activity of the presenting confereecomprises marking an area of the content.
 20. The method of claim 18,wherein the activity of the presenting conferee comprises pointing at anarea of the content.
 21. The method of claim 18, wherein the activity ofthe presenting conferee comprises scrolling the content.
 22. The methodof claim 18, wherein the original file format is a portable documentformat.
 23. A non-transitory machine readable medium, on which arestored instructions for a content receiving videoconferencing endpoint,comprising instructions that when executed cause the content receivingvideoconferencing endpoint to: receive presented content from a contentpresenting endpoint in its original file format; receive informationassociated with the presented content regarding activity of a presentingconferee on the presented content; and present on a display unit of thecontent receiving videoconferencing endpoint similar presented contentand the activity of the presenting conferee on the presented content asthe activity is displayed on a display unit of the content presentingendpoint.
 24. A non-transitory machine-readable medium, on which arestored instructions for a content transmitting videoconferencingendpoint, comprising instructions that when executed cause the contenttransmitting videoconferencing endpoint to: obtain a selected file ofpresented content in its original format; collect associated informationregarding activity of a presenting conferee on the file of presentedcontent; transmit the file of presented content toward a contentreceiving endpoint in the original format of the file of presentedcontent; and transmit the associated information to the contentreceiving endpoint.